用例分析——案例研究 - IT 觀察者隨筆

Table of Contents hide

用例是一種需求捕獲和文檔技術，可以用純文本編寫，以敘述方式描述使用系統的參與者的操作和交互。最後，系統的功能應該滿足利益相關者使用系統的目的。

在使用文本記錄用例描述之前，我們可以先使用用例圖突出顯示參與者使用系統的目的。通過圖形表示，您可以從鳥瞰圖快速了解整個畫面。定義系統的範圍（系統邊界）並確定支持使用系統功能或服務的參與者（稱為用例）的主要目標。

用例圖有利於團隊溝通，這是人類的天性：使用圖形通常比通過文字進行溝通更好。

在團隊對系統的整體外觀和感覺有初步了解和共識後，需求分析師打開橢圓形用例，並以正確且易於閱讀的格式描述參與者與系統之間的對話過程。

逐步提高用例的精度，從簡單到復雜。不要一開始就陷入複雜的細節中，以免在錯誤的設計和描述上投入過多的精力。用例圖有助於從簡單到復雜，並減少不必要的謬誤。

從圖中可以看出，本系統的設計範圍是“在線訂書系統”，使用該系統的主要參與者之一是“在線客戶”，使用該系統的參與者的目的是“訂書”。

“訂單簿”是系統的用例，參與者是“在線客戶”。在確定了參與者的目的後，我們會在文字敘述中記錄目的的細節，即記錄參與者之間的交互以及系統操作以達到目的。這稱為用例描述。

下表描述了一個簡單的“訂單簿”用例。

該用例由軟件巨頭 Jacobson 於 1992 年首次發布，對現代面向對象技術產生了相當大的影響。此外，由所謂的“三位朋友”——Booch、Jacobson 和 Rumbaugh 共同製定並經過 OMG 審查的 UML（統一建模語言）規範已被列為主要標準規範的重要組成部分。

以下是幾家軟件巨頭對用例的定義。

在《統一建模語言用戶指南》一書中，給出了用例的定義：

從上面的討論中，我們可以得到與用例相關的特徵：

用例是用自然語言描述的敘述文檔（如英語敘述）。一般來說，一個用例不涉及圖形或編程語言語法（如java）來描述。
用例中描述的場景正是參與者期望通過與系統的交互和通信來完成（獲得）他們的目標（Goal）。
例如，“購買商品”正是消費者消費的目的：
“消費者對購買的商品進行結賬，收銀員記錄購買的商品並收取貨款。一旦完成，消費者就會帶著商品離開。”
一個用例可以有一個正常場景，也可以有多個異常場景。正常場景描述了參與者與系統交互的正常過程；而在與系統交互的過程中，如果考慮到異常的發生，根據情況的複雜程度，可以用“正常場景下的“替代路徑”來描述，也可以用另一種方式來描述。複雜異常的場景。
系統將提供一系列功能與參與者進行交互，但參與者不需要知道系統中發生了什麼或如何去做，系統只需將結果發送回參與者即可。因此，對於參與者來說，系統是（或一組用例）一個黑盒子。
用例的描述強調系統應該做什麼（what to do），而不是如何做（how to do）。因此，在用例的描述中不應該描述實現的細節。
演員直接來到操作系統。在用例圖中，雖然參與者被表示為“簡筆劃”圖標，但參與者不一定是真人。參與者也可能是一個外部系統，它可能需要從這個系統中獲取一些信息。